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Abstract 


This RFC archives the report of the IETF - ITU-T Joint Working Team 
(JWT) on the application of MPLS to transport networks. The JWT 
recommended of Option 1: The IETF and the ITU-T jointly agree to work 
together and bring transport reguirements into the IETF and extend 
IETF MPLS forwarding, OAM (Operations, Administration, and 
Management), survivability, network management and control plane 
protocols to meet those reguirements through the IETF Standards 


Process. This RFC is available in ASCII (which contains a summary of 
the slides) and in PDF (which contains the summary and a copy of the 
slides). 
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Le 


Introduction 


For a number of years, the ITU-T has been designing a connection- 
oriented packet switched technology to be used in Transport Networks. 
A Transport Network can be considered to be the network that provides 
wide area connectivity upon which other services, such as IP or the 
phone network, run. The ITU-T chose to adapt the IETF’s MPLS to this 
task, and introduced a protocol suite known as T-MPLS. 


Quite late in the ITU-T design and specification cycle, there were a 
number of liaison exchanges between the ITU-T and the IETF concerning 
this technology. These liaisons can be found on the IETF Liaison 
Statement web page [LIAISON]. In addition, the chairs of the MPLS, 
PWE3, BFD, and CCAMP working groups as well as the Routing and 
Internet Area Directors attended a number of ITU-T meetings. During 
this process, the IETF became increasingly concerned that the 
incompatibility of IETF MPLS and ITU-T T-MPLS would "represent a 
mutual danger to both the Internet and the Transport network". These 
concerns led the chairs of the IESG and IAB to take the step of 
sending a liaison to the ITU-T, stating that either T-MPLS should 
become fully compliant MPLS protocol, standardized under the IETF 
process (the so-called "Option 1"), or it should become a completely 
disjoint protocol with a new name and completely new set of code 
points (the so-called "Option 2") [Ethertypes]. 


Option 1 and Option 2 were discussed at an ITU-T meeting of Question 
12 Study Group 15 in Stuttgart [Stuttgart], where it was proposed 
that a Joint (ITU-T - IETF) Team should be formed to evaluate the 
issues, and make a recommendation to ITU-T management on the best way 
forward. 


Following discussion between the management of the IETF and the 
ITU-T, a Joint Working Team (JWT) was established; this was supported 
by an IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T 
[ahtmpls]. The first meeting of the Ad Hoc group occurred during the 
ITU-T Geneva Plenary in February 2008. As a result of the work of 
the JWT and the resulting agreement on a way forward, the fears that 
a set of next-generation network transport specifications developed 
by ITU-T could cause interoperability problems were allayed. 


The JWT submitted their report to the ITU-T and IETF management in 


the form of a set of Power Point slides [MPLS-TP-22]. (See the PDF 
of this RFC.) The ITU-T have accepted the JWT recommendations, as 
documented in [MPLS-TP]. This RFC archives the JWT report in a 


format that is accessible to the IETF. 
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This RFC is available in ASCII (which contains a summary of the 
slides) and in PDF (which contains the summary and a copy of the 
slides). In the case of a conflict between the summary and the 
slides, the slides take precedence. Since those slides were the 
basis of an important agreement between the IETF and the ITU-T, it 
should further be noted that in the event that the PDF version of the 
slides differs from those emailed to ITU-T and IETF management on 18 
April 2008 by the co-chairs of the JWT, the emailed slides take 


precedence. 
2. Executive Summary 
Slides 4 to 10 provide an executive summary of the JWT Report. The 


following is a summary of those slides: 


The JWT achieved consensus on the recommendation of Option 1: to 
jointly agree to work together and bring transport requirements into 
the IETF and extend IETF MPLS forwarding, OAM, survivability, network 
management, and control plane protocols to meet those requirements 
through the IETF Standards Process. The Joint Working Team believed 
that this would fulfill the mutual goals of improving the 
functionality of the transport networks and the Internet and 
guaranteeing complete interoperability and architectural soundness. 
This technology would be referred to as the Transport Profile for 
MPLS (MPLS-TP). 


The JWT recommended that future work should focus on: 
In the IETF: 

Definition of the MPLS "Transport Profile" (MPLS-TP). 
In the ITU-T: 

Integration of MPLS-TP into the transport network, 


Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP 
and, 


Termination of the work on current T-MPLS. 


The technical feasibility analysis concluded there were no "show 
stopper" issues in the recommendation of Option 1 and that the IETF 
MPLS and Pseudowire architecture could be extended to support 
transport functional requirements. Therefore, the team believed that 
there was no need for the analysis of any other option. 
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The JWT proposed that the MPLS Interoperability Design Team (MEAD 
Team), JWT, and Ad Hoc T-MPLS groups continue as described in SG15 
TD515/PLEN [JWTcreation] with the following roles: 


Facilitate the rapid exchange of information between the IETF and 
ITU-T, 


Ensure that the work is progressing with a consistent set of 
priorities, 


Identify gaps/inconsistencies in the solutions under development, 


Propose solutions for consideration by the appropriate WG/ 
Question, 


Provide guidance when work on a topic is stalled or a techical 
decision must be mediated. 


None of these groups would have the authority to create or modify 
IETF RFCs or ITU-T Recommendations. Any such work would be 
progressed via the normal process of the respective standards body. 
Direct participation in the work by experts from the IETF and ITU-T 
would be required. 


The JWT recommended that the normative definition of the MPLS-TP that 
supports the ITU-T transport network requirements be captured in IETF 
RFCs. It proposed that the ITU-T should: 


Develop ITU-T Recommendations to allow MPLS-TP to be integrated 
with current transport equipment and networks, including in 
agreement with the IETF, the definition of any ITU-T-specific 
functionality within the MPLS-TP architecture via the MPLS change 
process [RFC4929], 


Revise existing ITU-T Recommendations to align with MPLS-TP, 


ITU-T Recommendations will make normative references to the 
appropriate RFCs. 


The executive summary contains a number of detailed JWT 
recommendations to both IETF and ITU-T management together with 


proposed document structure and timetable. 


These JWT recommendations were accepted by ITU-T management 
[MPLS-TP1]. 
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3. Introduction and Background Material 
Slides 11 to 22 provide introductory and background material. 


The starting point of the analysis was to attempt to satisfy Option 1 
by showing the high-level architecture, any show stoppers, and the 
design points that would need to be addressed after the decision had 
been made to work together. Option 1 was stated as preferred by the 
IETF and because Option 1 was shown to be feasible, Option 2 was not 
explored. 


The work was segmented into five groups looking at: Forwarding, OAM, 


Protection, Control Plane, and Network Management. The outcome of 
each review was reported in the following sections and is summarized 
below. 


There follows a detailed description of the overall requirements and 
architectural assumptions that would be used in the remainder of the 
work. 


4. High-Level Architecture 


Slides 23 to 28 provide a high-level architectural view of the 
proposed design. 


The spectrum of services that the MPLS-TP needs to address and the 
wider MPLS context is described, together with the provisioning 
issues. Some basic terminology needed in order to understand the 
MPLS-TP is defined and some context examples are provided. 


5. OAM and Forwarding 


Slides 29 to 32 describe the OAM requirements and talk about segment 
recovery and node identification. 


Slides 33 to 38 introduce OAM hierarchy and describe Label Switched 
Path (LSP) monitoring, the Maintenance End Point (MEP) and 
Maintenance Intermediate Point (MIP) relationship and the LSP and 
pseudowire (PW) monitoring relationship. 


Sides 39 to 46 introduce the Associated Channel Header (ACH) and its 
generalization to carry the OAM over LSPs through the use of the 
"Label for You" (LFU). 
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Slides 47 to 48 provide a description of how the forwarding and the 
ACH OAM mechanism work in detail. A significant number of scenarios 
are described to work through the operation on a case-by-case basis. 
These slides introduce a new textual notation to simplify the 
description of complex MPLS stacks. 


Note that the MPLS forwarding, as specified by IETF RFCs, reguires no 
changes to support MPLS-TP. 


6. Control Plane 
Sides 79 to 83 discuss various aspects of the control plane design. 


Control plane sub-team stated that existing IETF protocols can be 
used to provide required functions for transport network operation 
and for data-communications-network/switched-circuit-network 
operation. IETF GMPLS protocols have already applied to Automatic 
Switched Optical Network (ASON) architecture, and the JWT considered 
that any protocol extensions needed will be easy to make. The slides 
provide a number of scenarios to demonstrate this conclusion. 


7. Survivability 
The survivability considerations are provided in slides 95 to 104. 


The survivability sub-team did not find any issues that prevented the 
creation of an MPLS-TP, and therefore recommended that Option 1 be 
selected. Three potential solutions were identified. Each solution 
has different attributes and advantages, and it was thought that 
further work in the design phase should eliminate one or more of 
these options and/or provide an applicability statement. 


After some clarifications and discussion, there follow in the slide 
set a number of linear and ring protection scenarios with examples of 
how they might be addressed. 

8. Network Management 
Slide 106 states the conclusion of the Network Management sub-team 
that it found no issues that prevent the creation of an MPLS-TP and 
hence Option 1 can be selected. 


9. Summary 


Slide 113 provides a summary of the JWT report. 
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10. 


11. 


12x 


The JWT found no show stoppers and unanimously agreed that they had 
identified a viable solution. They therefore recommend Option 1. 
They stated that in their view, it is technically feasible that the 
existing MPLS architecture can be extended to meet the requirements 
of a Transport profile, and that the architecture allows for a single 
OAM technology for LSPs, PWs, and a deeply nested network. From 
probing various ITU-T Study Groups and IETF Working Groups it appears 
that MPLS reserved label 14 has had wide enough implementation and 
deployment that the solution may have to use a different reserved 
label (e.g., Label 13). The JWT recommended that extensions to Label 
14 should cease. 


The JWT further recommended that this architecture appeared to 
subsume Y.1711, since the requirements can be met by the mechanism 
proposed in their report. 


IANA Considerations 
There are no IANA considerations that arise from this document. 
Any IANA allocations needed to implement the JWT recommendation will 
be requested in the Standards-Track RFCs that define the MPLS-TP 
protocol. 

Security Considerations 
The only security consideration that arises as a result of this 


document is the need to ensure that this is a faithful representation 
of the JWT report. 


The protocol work that arises from this agreement will have technical 
security requirements that will be identified in the RFCs that define 
MPLS-TP. 


The JWT Report 


In the PDF of this RFC, there follows the JWT report as a set of 
slides. 
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